Date: Thu, 7 Jul 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #141 To: tcp-group-digest TCP-Group Digest Thu, 7 Jul 94 Volume 94 : Issue 141 Today's Topics: Amateur Radio AX.25 PBBSs vs NOS DOS (3 msgs) Index to the tcp-group mail archives LPD help PE1CHL Source Code? TCP-Group Digest V94 #140 Why not a solid PBBS prog .. or Net.TV ? Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Thu, 07 Jul 94 11:26:45 GMT-1 From: 86CS/SCMPA Subject: Amateur Radio To: TCP-GROUP@ucsd.edu My name is Eddie Coates, and I subscribed to the TCP-Digest in hopes of gaining more knowledge of packet radio. However, being that I am extremely new to the hobby, everything that I've read is way over my head. Could you reccomend a mailing list or two that might be aimed at the novice end of things. I would be grateful for any help. Also, I run an Amiga 500 and am interested in running packet radio with it. Can you push me in the right direction. Thanx in advance Eddie KB8FZQ ------------------------------ Date: Wed, 06 Jul 94 14:06:00 EDT From: "Battles, Brian" Subject: AX.25 PBBSs vs NOS To: Advanced Amateur Radio Networking Group WARNING: THIS IS A HUGE MESSAGE! 8-) (I accidentally left my Verbose parameter on!) =========BEGIN QUOTED MATTER======================================= Date: Fri, 1 Jul 1994 08:08:35 -0500 (CDT) From: ssampson@sabea-oc.af.mil (Steve Sampson) Subject: Stinkin' PBBS bbattles@arrl.org writes about what dgregor@bronze.coil.com writes: >> I've been thinking of something like this. If everyone could get together >> and write a good Amateur Radio PBBS program for Linux > why isn't there a good, solid, NOS-based PBBS package available for hams who > run DOS, Windows or OS/2 machines? Gary L. Grebus writes: > "Stamp out the PBBS in our lifetime." Gary speaks pretty much the opinion of most people that have been around packet radio for any length of time. If you really want to bore someone to death, have them buy a TNC and log into a PBBS for 10 days; then call the coroners office for a pickup. It's not something that gets better with age. Just like the bulletin board in the lobby of schools and offices, nobody ever reads it, but a lot of people stick things on it. Probably the only intelligent thing I've read on the subject of transfering information has to do with broadcast protocols. For example, it seems criminal that a PBBS would hand deliver copies to a circle of machines on the same frequency (eg, a satellite, or a town PBBS) when it could just broadcast the information while the others listened. The other really interesting article is "The HUB 5/29 IP Routing Experiment" in the 12th ARRL Digital Conference. Read this, and then decide whether you're still interested in a boring PBBS. Paul Overton and Ian Wade discuss a really nice routing scheme (only a mobile user would complain I suspect--but TCP/IP isn't ready for mobile/portable anyway) and then goes on to explain their modifications to NNTP that takes advantage of this. We've seen several automated IP routing schemes proposed, but the truth is that ham networks don't need them. If you have more than 3 entries in your routing table, you should read this article. I'd like to read more about this system and maybe see a distribution for others to duplicate. Basically I see no advantage of prolonging the PBBS given an operating network. The lack of a network is the reason the PBBS exists today. I think if towns or communities developed along the lines of the HUB 5/29 article it would make for a simple (easily duplicated) network scheme that could transport more substantial mail or news articles. I know this will never happen in Oklahoma because there's no organization, but other communities should look into this network and abandon the stupid PBBS, Rose and Netrom. Steve ------------------------------ Date: Fri, 01 Jul 94 15:55:24 From: kz1f@RELAY.HDN.LEGENT.COM Subject: Stinkin PBBS > Gary speaks pretty much the opinion of most people that have been around > packet radio for any length of time. If you really want to bore someone > to death, have them buy a TNC and log into a PBBS for 10 days; then call > the coroners office for a pickup. It's not something that gets better > with age. I couldn't agree more. However I think the real problem is the bulk of the PBBS users are running DOS (or maybe even Windoze) and use a terminal emulator or (terminal.exe) to log into their favorite PBBS. The machines are probably 286's and the memory is 640k. To answer Brian's question, the folks writing the 'really slick new" software aren't running 286s with 640k and given its such an labor of love to write this stuff they generally write it with the understanding that they too will use it. If I'm reading the sentiment right, one won't find any more DOS based xNOS's. There'll be char based Lunix or graphically based OS/2 or maybe even Windoze-based versions of TCP/IP suites that may not even support AX.25 mailboxes nor netrom....I know mine won't. Walt ------------------------------ Date: Fri, 1 Jul 1994 18:56:55 -0700 From: Phil Karn Subject: Why not a solid PBBS program? To: bbattles@arrl.org > Perhaps it would take a commercial venture to do it right. Would a PBBS >SysOp, who's spent maybe $1000-$2000 (or more) on radios, TNCs, antennas, >PCs, etc, also shell out maybe $50-$100 or so for GOOD software that beats >the heck out of the standard freebie AX.25 PBBS packages or the bazillion >semi-complete NOSs floating around? Why do we have to have PBBSs at all, especially if we're using TCP/IP? Why do hams have to keep reinventing the wheel, especially ones that aren't quite round? What's wrong with just using all the mail and news software that the rest of the Internet uses that seems to work fine for them? Why do hams always have to be different? Phil ===============END OF QUOTED MATTER======================================== I must say that I agree, in principle. Your everyday local DOS-based AX.25 PBBS is a neat resource that's become an anachronism with so many more advanced choices today. The simple problem is that the hundreds of PBBS SysOps and thousands of PBBS users aren't likely to drop everything and tackle that infamous "NOS learning curve" after they've just (in many cases) gotten close to mastering MSYS, W0RLI, FBBS, etc. We have to face it, in 1994, at least, your average amateur packet radio operator still sees TCP/IP as an "experimental" mode. But most packet ops have come to rely on packet (PBBS or DX cluster) as a service not unlike the telephone company. It's more a utility to them than a real "ham radio" mode. Thousands of radio amateurs operate their TNCs with dumb terminals, and they're satisfied. People who want file transfers rely on their cheap 14,400 bit/s telephone modems. Unsatisfactory experience with digipeaters and nodes has left many hams cold and uninterested in packet anymore, and unwilling even to try out TCP/IP. I know it's difficult for people like us to imagine, but I know young (teens through 30s), enthusiastic new hams who don't have the vaguest guess at what a DOS is or how to turn on a PC. Many of them, however, always hear all about packet from ham friends and are interested in getting started. Taking someone who doesn't even know the difference between an RS-232 connector and an ac cord and trying to describe how to operate a plain AX.25 TNC is a challenge; teaching them what TCP/IP is and how to use might well be a full-time job! There always have been and always will be amateurs with widely differing levels of knowledge, interest and experience. A few of us are comfortable with TCP/IP, HF DXing, contesting, ragchewing on repeaters, playing with RTTY, AMTOR, PacTOR and satellites, pointing ATV cameras at each other, running coommunity service communication activities, and piddling around with simple kits. Others use their licenses solely to experiment with VHF/UHF packet. The AX.25 PBBS network is a simple, "lowest-common-denominator" system for sending mail and ragchewing via keyboard (as mail or in real time). Personally, I feel that it would be far more efficient and productive to essentially let all the AX.25 PBBSs fade away to be supplanted by a national (worldwide?) network of TCP/IP users and Switches (ideally, all running *at least* 9600 bauds), with all sorts of useful, interesting Servers, Internet wormholes and gateways, and links to HF (ALE, Clover, G-TOR, whatever). Is this going to happen? Perhaps. Soon? No. Until TNCs come with built-in TCP/IP software and a friendly (GUI?) interface, learning to set MYCALL and TXDELAY, how to switch from cmd: to converse mode, and how to connect to a PBBS and list/read SALE@USBBS bulletins or DX spots is enough for most amateurs who own packet equipment. That is real life, outside these conferences and newsgroups. What's my point? Simply that AX.25 PBBSs are here to stay (for now) and the only way to get the main body of the packet population interested in TCP/IP and other advanced modes is to coexist with AX.25 PBBSs. This means gatewaying mail between AX.25 and SMTP, offering Telnet to users who enter the TCP/IP system via plain AX.25 connects, providing Convers servers (and other "goodies"), and perhaps even (shudder) inventing a truly efficient method to operate a DX cluster on a NOS-based station in a way that's better than AK1A's PacketCluster. All those SALE, WANTED, HELP, HUMOR, NASA, KEPS, AMSAT, ARL, DX, FEST, EXAMS, MODS, etc, bulletins have to be available to someone who dumps his PBBSing habit and commits a PC, radio, TNC and a bunch of hours of learning and tweaking to operating NOS. Why convert more packet operators from AX.25 to TCP/IP? Because every station running NOS can act as a link or even a Switch, if they're in an advantageous location and there's a need. There's no major functional distinction between one NOS user and another, as there is between a user and a PBBS in the "plain-AX.25" world. Very broadly speaking, more TCP/IPers means more service and connectivity, whereas more AX.25 users means more congestion and less efficiency. When it comes to TCP/IP (again, very generally speaking), the more users, the better. Not to mention that larger local groups means more people potentially willing and able to pool resources to invest in central LAN Switches with duplex repeaters and dedicated Switch-to-Switch links. There's no need to "dilute" NOS or try to mash in enough code to turn it into a completely "dual-personality" AX.25 PBBS and TCP/IP combo-in-a-box. But it would be useful to see a reasonably smooth (I hate the word "seamless") system for intermingling as much of the two flavors of packet as possible, at least until TCP/IP users clearly outnumber AX.25 packeteers. ========================================== Say, here's a rare opportunity: I "guest wrote" what's planned to be the Packet Perspective column in September '94 QST. Here's my first draft...have a gander at it (especially the last paragraph) and shoot me e-mail if you have any substantial, specific points you want o clarify, correct or submit an opinion about. No guarantees about whether I'll use it, or even that my final draft will look much like this, but I'd like to see how you as an informed packet operator feel about this: Packet Perspective @USBBS Anyone who has visited the Never Land of written electronic communication knows that the open forum provided by telephone bulletin boards (BBSs), the Internet and other similar media have long offered users exciting, effective means of discussing, debating and announcing diverse opinions, issues and emotions. These environments have traditionally relied on two basic means of controlling the content of messages posted and behavior of those who choose to participate: (1) a "gatekeeper" and (2) peer pressure. The gatekeeper (SysOp) can decide who may post material, what may be posted and if it will be forwarded. Peer pressure, the most visible yet least powerful, provides a vocal, but ultimately impotent form of obligation to conformity. It does this through friendly advice, admonishment, chastisement and outright insult. In amateur packet radio, a third entity wields a measure of control: The regulator (the FCC), which determines what is legally acceptable. Traditional wired networks, such as the seminal Fidonet, maintain an accepted level of decorum through a time-honored voluntary standard of cooperation and a well-defined hierarchy of people who have definite levels of enforcement authority. Specific areas, also known as "conferences" or "forums" (or Echoes, in the case of Fidonet), are designated where users may write messages pertaining to that area's usually narrowly defined topic. A volunteer, often selected by conference participants, acts as moderator. This person's job is to regularly post a set of conference rules, to monitor the posted messages and to point out transgressions. Theoretically, the moderator's presence is to serve as a referee, to inform users of transgressions and to reduce the amount of peer-to-peer bickering among users over each others' perceived misbehavior. Users who repeatedly violate the rules after sufficient warnings from the moderator are reported to the SysOp of the site where the user logs in to post messages, who provides the offending user access to the conference. It becomes the SysOp's responsibility to counsel, rehabilitate, educate or bar the user's access to the conference. The SysOp is motivated by the potential consequence of having his BBS excommunicated from the network if he fails to exercise the proper control over his users' behavior. In the world of amateur packet radio bulletin boards (PBBSs), however, there are differences that make control and adherence to standards difficult to implement. For one thing, open packet bulletin traffic isn't carried and categorized in distinctly separate "conferences" that a user may conveniently choose to read or ignore by simply selecting from a menu. All packet bulletins are mixed into a homogenous list that users see whwnever they log in and request a listing of the day's latest mail. Second, the spirit of democratic, uncensored participation that offers many advantages to radio amateurs precludes most SysOps from refusing access to uncooperative users, and even pressures them to make undesirable messages available to all of their local users, and even to forward such messages to other PBBSs in the network. SysOps have been roundly and publicly criticized for refusing to forward bulletins they deemed to be inappropriate, even if only for purely technical reasons. In many raging discussions, users have maintained that a SysOp is obligated to accept and forward their message without question, as long as it doesn't expressly violate any FCC rules. (This is, by the way, entirely untrue. According to the law, no SysOp is under any obligation to do anything whatsoever with any radio amateur's messages, and the law also states that a PBBS is its SysOp's privately operated radio station, for which the SysOp is permitted--in fact, expected--to monitor and control the material it transmits.) Educating Users To turn to a more basic, pragmatic issue, many packet operators have spent many hours discussing the frustration of having these PBBS, supposedly design and built for the main purpose of carrying person-to-person mail traffic and occasional bulletins of general interest, into electronic "classified ad pages." Notices that carry announcements of items for sale, swap or wanted, noticeably far outnumber every other single type of bulletin. Because of its convenience, low cost and apparent effectiveness, PBBS users indundate the airwaves with a nationwide swapfest day and night. Most messages in this category are individually harmless, but when viewed as a class, are the greatest consumers or computer storage space, message-forwarding time and bandwidth. Many SysOps, and more PBBS users, complain that all you ever see listed on a PBBS today are screenfuls of "SALE@USBBS" messages and so on. It's an understandable lament: There's a lot of stuff in there, but most of it is "junk mail" most users will never read. For example, a ham in Boston isn't likely to care about a personal computer or hand-held transceiver being sold by an amateur in Seattle. But there are hundreds, perhaps thousands of amateurs in Washington or perhaps the Pacific Northwest region who will read and respond to such a notice. So why waste the time and bandwidth to send this bulletin ping-ponging all over the US by adressing it so it's forwared to "@USBBS"? In a sadly ironic way, most packet messages posted aren't nearly as efficient as the non-SysOp packet operator believes. It's common to see items too insignificant or unwieldy to be easily sold to amateurs hundreds of miles away sent out addressed to "FOR SALE @ USBBS," a lazy, or perhaps misunderstood format that causes thousands of amateurs in Alabama, for example, to have their local PBBSs spew forth several screens full of listings for hand-held transceivers, parts, batteries and other such items that are being offered by hams in Oregon or Alaska, and that are likely to be sold by the time they reach most out-of-state PBBSs. SysOps: Can You Do It? Perhaps there needs to be a system implemented by which SysOps would be asked to voluntarily help educate users by requiring the user to read an educational message about the most appropriate way to address bulletins before the user would be given the privilege of posting a message that was intended to be forwarded to other PBBSs. This would require at least two things: (1) The PBBS software would have to support a method of doing so, and (2) The SysOp would have to be willing to invest whatever additional time it might take to grant access to potential users who acknowledge that they've read and understand the proper procedure. Is it reasonable to suggest that PBBS SysOps route incoming messages addressed to @USBBS" to some kind of holding bin, unless they meet certain criteria (eg, ARL, KEPS, AMSAT, FCC, SYSOP, DX, etc)? For example, do we really need so many SALE, WANTED, HELP, FEST and EXAM bulletins addressed to, and circulated over the airwaves to, @USBBS? Does it offer any real advantage to the user who posts it? Isn't it more efficient, timely and appropriate to post most bulletins to a local, state or regional circulation? Could PBBS SysOps do this, and would they want to? How much extra time and effort would it take? Can any of this be automated? Will an investment in the time and energy now pay off later with less "junk mail" coming through each PBBS in the near future, if users can be taught to cut down the unnecessary "@USBBS" traffic?And how much actual improvement would that offer all amateurs, regarding the possible decrease in traffic transmitted via VHF/UHF backbone and HF forwarding? This could certainly be implemented in a friendly manner, with errant users gently instructed in a friendly, helpful manner. Each PBBS SysOp could prepare a "boilerplate" text he could use to inform a user whose postings were held or rerouted that would explain what was done, why it was done and how to avoid such faux pas in the future. A standard one-page (one screen?) message from the SysOp could simply inform the user that @USBBS is, by conventional agreement, reserved for messages that, by their inherent nature, lend themselves most advantageously to distribution to the entire nation's amateurs. It could advise the user that buying, selling, swapping or evaluating almost any Amateur Radio item could be quite effectively accomplished via a local or regional bulletin, and that he should seriously consider if the hams in a distant state will care or be able to take advantage of the information in certain types of messages. The Alternative This primarily concerns standard AX.25 PBBS users and SysOps because more advanced software, such as that used for TCP/IP networking, doesn't even involve PBBSs, as most hams know them. A TCP/IP user finds his mail forwarded neatly stored in his own private mail area on his own computer's disk drive. Bulletins can be forwarded only to TCP/IP operators who specifically request them, by category, from stations that act as "gateways" to collect useful bulletins from local AX.25 PBBSs and mail them directly to those who want to see them. Ideally, if all US packet stations operated TCP/IP software, rather than standard, "built- in" AX.25, the traditional PBBS could be eliminated and amateur packet radio would function more like the Internet. Each station would be accessible directly by every other station, and each amateur could choose to "subscribe" to "newsgroups" that encompass particular topics. Let's hear what you think, as a packet operator, and especially as a PBBS SysOp. Poke holes in my suggestion or offer ideas on how to improve it. Be constructive and thoughful, and perhaps we'll be able to slowly educate our fellow packet operators so that we can all help each other maintain, expand and speed up our powerful, impressive amateur packet radio network. CUL es 73 de BB ___________________________________________________________________________ Brian Battles, WS1O I Internet bbattles@arrl.org I "Radio amateurs QST Features Editor I Compu$erve 70007,3373 I do it with high ARRL HQ I MCI Mail 215-5052 I frequency" Newington, CT USA I Tel 203-666-1541 I Amprnet ws1o@ws1o-2.ampr.org [44.88.2.43] Fax 203-665-7531 I AX.25 packet WS1O @ W1EDH.CT.USA.NA BBS 203-666-0578 ___________________________________________________________________________ COMMENTS EXPRESSED HEREIN ARE MY OWN PRIVATE, PERSONAL REMARKS AND ARE TOO INANE TO BE CONSIDERED OFFICIAL ARRL VIEWS OR POLICY. ------------------------------ Date: Wed, 06 Jul 94 16:00:05 From: kz1f@RELAY.HDN.LEGENT.COM Subject: DOS To: "TCP digest" I must add my two cents in here. I understand the sentiment behind bad-mouthing DOS (its so easy to do). But I dont understand the mad rush to replace it with a version of Unix, free or otherwise. In this day and age its a real labor of love to learn the Unix cmds and associated flags. It may have one advantage though, one doesnt need to write a xNOS to run onit, merely write the appropriate driver for the tnc or PI card. But I can't imagiine there are that many folks interested in learning how to write device drivers, for DOS, OS/2 or Unix. Am I missing something here? Walt kz1f@relay.hdn.legent.com ------------------------------ Date: Wed, 6 Jul 1994 16:22:25 -0700 (PDT) From: Lyndon Nerenberg Subject: DOS To: kz1f@RELAY.HDN.LEGENT.COM On Wed, 6 Jul 1994 kz1f@RELAY.HDN.LEGENT.COM wrote: > I must add my two cents in here. I understand the sentiment behind > bad-mouthing DOS (its so easy to do). But I dont understand the mad rush to > replace it with a version of Unix, free or otherwise. In this day and age > its a real labor of love to learn the Unix cmds and associated flags. Can you say client/server boys and girls? I *knew* you could :-) Use the Unix box as the news/mail/convers server. Let the end users run Windows based clients talking IP over the radio. Everyone gets to use their favorite software and nobody has to learn to type 'man'. The scary thing is that *all* the application software has already been written. All that's missing is a packet driver that knows how to talk to a TNC and fake out AX25 callsign/SSID MAC addresses as if they were Ethernet MAC addresses. --lyndon ------------------------------ Date: Thu, 07 Jul 1994 12:50:42 +1000 From: ccdrw@cc.newcastle.edu.au (Dave Walmsley) Subject: DOS To: tcp-group@ucsd.edu Lyndon et all. My thoughts when Johan defected ;-), we just need a Winsoc or packet driver that sits below all the goodies that live on the net. I wish I had the knowledge and time to get such a project started. >The scary thing is that *all* the application software has already been >written. All that's missing is a packet driver that knows how to talk to >a TNC and fake out AX25 callsign/SSID MAC addresses as if they were >Ethernet MAC addresses. > >--lyndon > Dave ========================================================================= Dave VK2XPX, sysop VK2RAP ccdrw@cc.newcastle.edu.au sysop@vk2rap.newcastle.edu.au vk2xpx@vk2xpx.ampr.org ========================================================================= ------------------------------ Date: Thu, 7 Jul 94 01:26:16 +0100 From: Adrian Godwin Subject: Index to the tcp-group mail archives To: tcp-group@ucsd.edu As I suggested earlier, I've made a first stab at a topical index of the tcp-group mail archives. It's rather slow work, and the only other volunteer is looking at using WAIS in the hope of producing a longer-term solution, so I've only done 1987 so far. This index is on ftp.ucsd.edu as hamradio/packet/tcpip/incoming/tcp-group-index.87a.gz I'm holding indexed articles in MH folders, but I didn't want to upload the entire archive in this form. For the moment I've just created a file containing a list of topics and pointers (in the form of subject // author // date // message ID) to the articles. This is probably useable as input to a reformatter for a browser such as WWW, but may be of little use for manual browsing in the meantime, especially as the 1987 files are simply two simple mail folders - you have to download them and search for the index entries, and the lines in the index are rather long. I'd appreciate comments on : - a more useful format for the index - my arbitrary choices of topic title and group - the granularity of the topics - pretty well anything else relevant By 'topic' I mean the name for a series of threads on related subjects. By 'group' I mean a series of vaguely related topics. This should be pretty obvious from the index file. The topic list started out as a bunch of likely topics off the top of my head and was adapted slightly as I went along. As a result, some articles are doubly-indexed (I consider this a feature, not a bug) and some topics are empty (for the moment). Note that I've no intention of setting up a browser for this myself - long term, a WWW server on ucsd (and perhaps a WAIS interface) is the aim. -adrian, g7hwn ------------------------------ Date: Wed, 6 Jul 94 04:00:56 CST From: Jack Snodgrass Subject: LPD help To: tcp-group mailling list I've compiled in the LPD stuff with JNOS, but can't figure out if it works or how to use it. Has anyone else figured it out? I'd appreciate if someone who's using LPD with NOS could send me a working printcap example. I'm using a Canon BJ-200 printer ( IBM ProPrinter compatible ) on LPT1 but I'd like to see ANY WORKING /etc/printcap example that defines a printer on LPT1. Thanks. 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 Dialup - kf5mg@tcet.unt.edu - work (looking for) ------------------------------ Date: Thu, 7 Jul 94 09:52 +1000 From: ANDY JOYCE Subject: PE1CHL Source Code? To: TCP-Group@ucsd.edu Hi all, Im working with some project students here at QUT who will be using TCP/IP and the FTL0 Pacsat broadcast protocol for use within the TSG Telemetry Systems Group within the University here. We would like to add some station control code to the PE1CHL version of NOS that also uses the FTL0 protocol. The problem is that we have been searching high & low for source code or an Email address to PE1CHL, but we cannot find either? Does anyone know if source code for PE1CHL-NOS is available and/or a FTP site, or either a Email address so we can contact PE1CHL direct... Thanks.. Andy Joyce VK4KIV AARNet/Internet - A.Joyce@qut.edu.au AMPRNet/Packet - vk4kiv@vk4kiv.qut.ampr.org Queensland University of Technology: ------------------------------ Date: Wed, 6 Jul 1994 10:05:07 -0600 (MDT) From: Tim Baggett Subject: TCP-Group Digest V94 #140 To: Advanced Amateur Radio Networking Group > Karl writes: > > [Stuff deleted] > > > I have read guys saying Linux is the way to go and I say bull > > pucky! Linux to have ANY speed must live in 8 meg of ram on a 88486-50. Well Karl, as you know, I just got Linux installed on a 386dx-25mhz, 8 mb RAM machine here at school. Its not a Sun SPARC 10, but I can see power roaring under the hood already. Actually I'm quite content with the speed, so far. > > This translates into a MUCH more expensive computer and I'm not sure you > > can boot up in Linux without dos being present. Need to run an experiment. No MS-DOS present at ALL on my Linux machine (YEAH!). Boots right up into Linux. Not even the slightest hint of MS-DOS. I wiped that sucker clean out when I formatted the hard drive :-) > > As one tag line says " Are you still using dos? Pity" I say if > > you are paying for your software dos is a good deal. So is Windows ver > > 3.1 and a host of other software written for dos. From my point of view > > going back to UNIX with it's $2,000.00 software is a real BAD idea!! Well, Linux cost me about $20 worth of disks to put it on. Snag it from net.tamu.edu. Finally, I found out what your supposed to do with a PC clone (besides using it as a door-stop, which people at work tell me) - format the HD and install *NIX :-) :-) Linux is just like the big machines, and real timesharing! none of this crowbarring it into MS-DOS (Although you did a good job of forcing MS-DOS to do it Phil!) 73 Tim ******************************************************************** Tim Baggett, AA5DF Electrical Engineering Student New Mexico State University Internet: WBAGGETT@NMSU.EDU AMPR: AA5DF@NMSUGW.AMPR.ORG US Snail: 1805 Rentfrow Apt #1 (When on) AA5DF.AMPR.ORG Las Cruces, NM 88001 ******************************************************************** ------------------------------ Date: Wed, 6 Jul 94 16:21:03 PDT From: efb@suned1.nswses.navy.mil (Everett F Batey) Subject: Why not a solid PBBS prog .. or Net.TV ? To: tcp-group@ucsd.edu Perhaps a look at Broadcast / Multicast Internet television would give us a model to consider .. Saw it running at ISI last year so .. if we have a backbone equivalent then we can spread tiled pictures ( a la CCITT- Gp4 ) or send newsgroups .. // -- + efb@suned1.nswses.Navy.MIL efb@gcpacix.uucp efb@gcpacix.cotdazr.org + + efb@nosc.mil WA6CRE Gold Coast Sun Users Vta-SB-SLO DECUS gnu + + Opinions, MINE, NOT Uncle_s | WWW b-news postmaster xntp dns WAFFLE + ------------------------------ End of TCP-Group Digest V94 #141 ******************************